The Internet came into being in its current form in 1983 when all the computers connected to ARPANET—a military network—began using the same communication protocol. In 1986 ARPANET became NSFNET in a bid to link the USA's supercomputers. E-mail began to be commercially available in 1990 at much the same time that Mosaic—the first worldwide web browser—became a useful product. The Internet, comprising mainly the WWW (world wide web) and e-mail is now an extremely important business tool.
The world is now networked, much of this provided by TCP/IP (Transmission Control Protocol/Internet Protocol) but ATM (Asynchronous Transfer Mode) is still dominant in telecommunications. Most major companies have access to the Internet and the Internet backbone runs thru much of our environment. This infrastructure is made up from largely fixed, rigid connections; wires, routers, switches and similar.
Human beings tend to move around when engaged in work and leisure. An easy way to connect to the fixed network is needed for these mobile users. Mobile users are commonly envisaged as people using a cell phone or other radio device, but for our purposes a ‘mobile user’ is anyone away from their fixed home base.                1. Wireless connections are inherently expensive as they use a rare resource—radio frequency spectrum—and require large infrastructure investments.        2. There are practical difficulties when away from home base, such as determining IP addresses, proxy server settings, negotiating billing and payment and security and privacy concerns.        
Even the simple task of moving from one office to another within the same company can be fraught with complications and more often than not people fail to make connection when traveling away from home base. With so many companies relying on e-mail and the World Wide Web as a critical business tool, an inability to connect can prove costly to companies. In the last three years the ability to access the Internet has begun to migrate to mobile devices. Small mobile devices have tended to use a variety of specialist Internet access methodologies with varying degrees of commercial success. They all suffer from the limitation of low bandwidth and high cost.
There are a number of methods by which users can get access to data from mobile wireless devices: SMS, HDML, WAP and I-Mode being the main standards. All of these standards suffer to some extent from problems such as limited bandwidth and complex authoring environments.
In SMS (short message service) users can send and receive simple, short text messages from their phone. A server at the mobile phone service either routes them to other mobile phone users or provides a gateway that translates the messages and sends them as e-mail to Internet e-mail services. The gateway will also translate incoming email and send it to the user in SMS format. Although rudimentary, large successful businesses have been founded from sending these short messages demonstrating that people need data on the move and are prepared to pay for it.
In HDML (Handheld Device Markup Language) a web site is composed using specially modified tags. A wireless gateway translates these tags so that the mobile device may view them. A mobile device equipped with a micro browser capable of interpreting HDML can display this information on a small LCD.
In WAP (wireless application protocol) a web site is composed using WML (wireless markup language) and this information sent to a WAP gateway. The user gains access to this gateway either by dialing a RAS (remote access server) or by using a packet based system, commonly referred to as ‘always on’.
In I-Mode specialist tags are again used to create pages formatted in compact-HTML. These are served over a gateway to users on a packet-based system.
In the above systems a specialist gateway is used to provide output formatted for mobile devices. An alternative method of accessing the Internet from a mobile device is provided by fixed wireless systems such as Bluetooth and the IEEE 802.11 wireless LAN standard.
In the 802.11 and Bluetooth standard two wireless devices establish a point to point or point to multi-point link using spread spectrum radio technology. The two wireless devices can be any type of electronic appliance—PC, PDA, Cell phone, microwave oven, home security system. This link replaces wires and does nothing to reformat the content of data.
Another wireless standard that has reached ubiquity in availability but has very little usage is IrDA (Infrared Data Association). In the IrDA standard two devices with IrDA capability positioned near one other can communicate using infra-red beams. The standard suffers from two problems. Firstly that the link is optical and therefore requires a clear line of sight. The devices must be positioned so that their ports are visible to each other or at least so that sufficient reflected light reaches the, ports. Secondly the two computers need to have their IrDA ports configured and switched on. This is a non-trivial task: The hardware must be enabled—commonly powersaving and compatibility issues mean that computers are shipped with the port disabled. A device driver must be installed. Once the physical link is available a logical link is needed to allow file transfer or access to the hard disk of the companion computer. Security and privacy must be ensured.
Looking at problems of getting Internet access when mobile a number of steps are required.                1. Some form of driver software is needed to configure the user's hardware to allow a link to be made.        2. The physical link needs to be made. This may be by pointing the two computers at each other or connecting a back-to-back USB cable, which has been provided by, for example, the hotel at which the user is staying.        3. The host user needs to enable and share certain services, such as printers and hard disks and network connections.        4. The host user needs, itself, to log onto the Internet.        5. The host user needs to act as a gateway for the connecting user, translating and forwarding packets onto the Internet.        6. The IP address of the host's interface needs to be configured to a non conflicting address with that of its Internet link.        7. The IP address of the connecting user needs to point to the host user.        8. The ports and proxy servers need to be set up. Even if no special set up is required a user who normally works in a corporate network with special settings will need to write these down and then delete them from the system, remembering to type them back in when returning to the corporate environment.        9. If the link has a cost to it a financial transaction needs to be entered into with metering and billing.        10. No simple solution is available to ensure a secure link.        11. E-mail may or may not require yet more steps to enable.        
This multi-step process is fraught with difficulties and there are numerous potential points of failure. Most connections fail because either one of the steps cannot be completed, or each step is so time consuming that the user gives up before completing the task. Since mobile users are usually short of time, have limited resources (such as driver disks, spare cables) and have to configure multiple times as they travel thru different environments, the effort is very frustrating. Typically the above exercise is completed around 30% of the time with a mean time of effort of two and a half hours. Although many operating systems (such as Windows 2000™) allow connection sharing the implementation of these makes the task very complex.
An additional further complexity has been generated by the lack of interoperability between IEEE 802.11 and Bluetooth. Since both standards operate in the same frequency spectrum the two systems will tend to interference with each other.
Additional difficulties occur when a firewall is present. If a shared connection is obtained in the home or office, access to the Internet may be blocked or restricted by the activities of a firewall. The same technology that provides the firewall capability may also track usage and web sites visited providing a risk to privacy. Additionally information that is sent or received may be logged causing considerable security risk.
Although the cellular system provides some degree of roaming it provides no solution to inter-system roaming and uses expensive infrastructure, which results in high call cost. In addition the process of connecting a PC or PDA to a cell phone is complex and requires considerable reconfiguration of the device. The current mode of access to the Internet is predominantly through a one-to-one commercial negotiation. Each person has a connection to the Internet via their own ISP. When visiting someone else's home obtaining access to the Internet is difficult. Calling the ISP requires another phone line. In the case of ADSL or cable systems the MAC address of the network adaptor is registered to the ISP so that a second user can't use the connection. You can install a network and enable connection sharing in your OS—for example Windows 2000™ but this involves a number of complex steps. In addition there is a significant security implications to this. Generally home and commercial networks are not set up with the anticipation that roaming users will be physically connected to the network inside the Firewall. Thus many network services are not secured against internal access. (It is not uncommon for a corporate network running Windows™ 2000 to have numerous hard disks shared without passwords.) Although the firewall blocks this from external access, a local connection would be inside the firewall.
Although these problems have existed for some time, the emergence of Bluetooth and IEEE 802.11 are encouraging people to connect more often. While the above discussion is centered on the difficulty of human beings obtaining connection to the Internet it should be bourn in mind that autonomous machines have similar difficulties. Much talk is made of microwave ovens, video recorders and refrigerators talking together using home networks. It is also envisaged that automobiles will be similarly equipped. These systems are likely to become ubiquitous over the next five years as networking capabilities are built into appliances. These devices need to obtain services from somewhere and need to obtain a connection to the Internet. It will be prohibitively expensive to give each device it's own dedicated connection. The devices will also need services tailored to them. One can consider that an appliance once manufactured an shipped becomes a roaming device in need of connection to the Internet.
As described above, there are two main types of wireless network present in the world today—wide area networks (WWAN) exemplified by cellular systems and local area networks (WLAN) provided typically by 802.11 (also referred to generically as “Wi-Fi”) and Bluetooth technologies. Some examples are named in Table 1 set forth below.
TABLE 1WWANWLANGSMWi-Fi (802.11 a/b/g)UMTSBluetoothW-CDMADECTCDMA2000ZigBee (802.15.4)FOMAWiMAXTETRAHomeRFGPRSHyperLANHSCSDHSDPAEDGE
Some technologies defy this simple classification. Bluetooth, when used in its low power mode, is often called a personal area network (PAN) and WiMAX technology can have extended range that rivals cellular macro-cell coverage. The distinctions can often be based on heritage and infrastructure ownership, but nevertheless today there is general agreement on the two classifications and the distinction between them—a WWAN connects to the core cellular network first, while a WLAN connects to a computer network first.
A complication of WWANs in particular, but all networks in general, is that they distinguish between voice bearers and data bearers. Thus in GSM there are GSM audio channels and GSM data channels such as EDGE. For the purposes of this patent, WWAN-audio and WWAN-IP (-Internet Protocol) will refer to these distinctions respectively. Additionally, WWAN-VoIP (-Voice over IP).will refer to the situation of carrying voice over WWAN-IP.
A number of methods have been proposed for implementing mobile voice and data systems so that they operate on both WWAN and WLAN based infrastructure. In implementing such mobile voice and data systems, these systems will have to deal with the problems of roaming and handoff between them. Roaming is the feature where a mobile phone can acquire a radio connection and signal to an authentication method to request a connection to services, while handoff is the feature where a mobile phone moves from one radio connection to the next maintaining a voice call or data connection with as little interruption as possible. When this interruption is not noticeable to the user the handoff is deemed “seamless.” Seamless handoff is not always an advantage. For example, when the user moves from a low cost connection to a high cost connection they generally want the transition to be made clear. The ability to do seamless handoff is an important feature of these systems even if, on occasion, it is deliberately switched off or the handoff made non-seamless through the use of notifications. When a mobile phone moves from one radio connection to another and the bearer technologies are the same we will hereafter refer to this as handover to differentiate it from handoff—for example when moving from one Wi-Fi access point to another.
Two types of systems that have implemented mobile voice and data systems that operate on both WWAN and WLAN based infrastructure are; (1) UMA-based systems and (2) Bluetooth CTP-based systems.
UMA-Based Systems
The most prominent standard for WWLAN to WWAN interoperability is the Unlicensed Mobile Access (UMA) system, whose specifications can be obtained from www.umatechnology.org. UMA technology provides a method for using the cellular network infrastructure and specially modified handsets with WLAN Access Points (APs) to implement micro-cells in the network. UMA is described in relation to the GSM system but can be generalized to WWAN-Audio systems including 3G. We shall refer to the GSM case for this discussion. In the UMA system a handset is modified to send voice and data via a WLAN connection (such as 802.11 alb/g or Bluetooth). When using the WLAN connection, the GSM protocols (speech encoding and mobility management et. al.) are encapsulated and sent over WLAN via an access point which routes traffic to a UMA Network Controller (UNC) that de-encapsulates the protocol and sends it on to the cellular infrastructure. The primary object of the UMA specification is to make connection to the core cellular network as quickly as possible and then make all further communication through that core cellular network.
Roaming is possible on UMA because the protocol encapsulation and emulation of a GSM base station allows the handset-AP combination to appear as a GSM cellular phone and GSM base-station even though the wireless protocol being used is WLAN. Handoff is supported between cells where the initial cell is a WLAN-AP and the handoff is made to a GSM cell or vice versa. In these cases the handset must simultaneously switch radio layer protocols while maintaining the GSM signaling and audio channel connectivity.
Because of this requirement to emulate the GSM cellular protocols (signaling and voice) in complex handoff scenarios these systems suffer from a number of practical problems: The GSM specification was not written with the assumption that the radio layer could change mid way through a transaction and it therefore organizes the signaling channel with precise time slot assignments, interleaved with the voice channels. Implementation of UMA therefore requires complex integration with the GSM software stack at a low level in the phone such that the phone can perform these handoff tasks.
In particular the phone may signal a handoff ‘start’ while using one radio layer and then signal the handoff ‘completion’ using another radio layer. Because of these timing, slotting, encapsulation and signaling elements, the system design is complex with many points of integration between the WLAN signaling elements and the GSM elements at low levels in the stack. Presently, such low level integration requires considerable engineering time to implement as the software elements are real-time and time critical—often upwards of 18 months for software work, manufacturing and test prior to launch in the network.
While these time scales are appropriate for products in the mobile domain the convergence of fixed and mobile networks brings Internet development timescales into play with the problem that by the time deeply embedded, real-time software stacks have been implemented for a phone it is often the case that the Internet protocols have moved forward or the handset is obsolete before launch. Even with considerable design effort system performance can still be limited with handoff failures and interoperability restrictions.
In addition, although the specification calls for the use of standard access points, in practice the access points have to be specially designed to cope with the timing requirement inherent in the protocol management and this means the systems can not work with general purpose access points such as those deployed in the market already in hotspots, homes and offices. This need to specifically design each AP dramatically increases the total cost to deploy a system as every Access Point must be visited where the older units need to be swapped out and the newer unit installed.
In addition UMA handsets require a full cellular infrastructure to operate, consisting of a Mobile Switching Centre (MSC) within the HPLMN (Home Public Land Mobile Network) interworking with location databases including HLR (Home Location Register) and VLR (Visitor Location Register) or SGSN (Serving GSM Support Nodes). This requirement is disadvantageous because it is architecturally complex—data packets must transit through the cellular system even when they originated from WLAN Access Points as Internet Protocol (IP) and are often destined to terminate via IP, say as a VoIP call, thus putting unnecessary stress on these systems and causing numerous unnecessary protocol translations that introduce latency and potential for failure. A call which might have been routed locally perhaps over only a few hundred yards of IP cabling will have to transit through the entire cellular core network. So a UMA protocol based system is essentially incompatible with peer-to-peer routing and SIP based RTP stream direct connection paths. Also, many companies that want to utilize voice and data services over wireless do not possess core cellular network infrastructure and such infrastructure is extremely expensive to purchase and the arrangements for leasing capacity are generally unattractive.
Bluetooth CTP-Based Systems
Another implementation of a mobile VoIP system entails using a phone that supports the Bluetooth cordless telephony protocol (CTP) connecting to a Bluetooth enabled base station that also supports CTP. A CTP system implements two protocols: telephony control specification—binary (TCS-binary) and the synchronous connection oriented (SCO) audio protocol. A call is initiated between the phone and the access point using the TCS-binary protocol to initiate off-hook, dial-tone, and send and confirm the number. Once the call is connected, audio is transmitted directly from the microphone and speaker hardware to the Bluetooth low level stack, usually a hardware implementation, and then over the air interface to the AP's audio hardware which then needs to encode the audio in a suitable form for onward transmission.
There are a number of problems with this:                i) The cordless telephony protocol implements ‘SCO-Audio’ which is a fairly simple high bandwidth audio compression/decompression algorithm (codec) that is not particularly well protected from interference by other radio devices; this limits range.        ii) The codec used by CTP is not directly supported by Session Initiation Protocol (SIP) servers used in Internet telephony and so the stream has to be re-encoded by the CTP-enabled base station. Re-encoding with different compression can produce serious audio artifacts, takes processing power, increases latency and substantially reduces the Mean Opinion Score (MOS) by which people rate the quality of sound.        iii) The CTP algorithm is not IP based and so when switching from one network (Bluetooth) to another (WWAN or WLAN), the phone and AP must swap protocols. This typically involves unhooking the Bluetooth hardware audio system and re-initialing a completely new audio path through the phone's digital signal processing (DSP) subsystem which causes an interruption in the audio stream and a change in the audio characteristics requiring an end-to-end renegotiation of elements such as CODECs, Quality of Service (QoS) and echo cancellation parameters. A similar reconfiguration of the AP is also needed.        iv) Differing compression algorithms are used on the differing radio connection methods and this makes for very complex control when trying to throttle bandwidth.        v) Because CTP is a relatively high bandwidth protocol and because CTP is a low level timing critical protocol few connections can be supported by an AP. Three connections can be supported in theory, but only one connection is often feasible in practice.        vi) CTP is implemented at a very low level in the protocol stack and takes audio directly from the microphone and speaker into the Bluetooth audio codec. This means that the higher levels of software have no control of this path to implement elements such as mixing, echo cancellation, improved CODECs, or indeed any extension to the basic audio functionality available.        vii) Finally, the CTP protocol must be implemented in the handset and the AP at a hardware level and interoperability tests performed.        
Again, deep integration is needed to implement CTP which is time consuming and expensive and this has not been implemented by several manufacturers. For example Nokia™ does not support CTP on their phones and Microsoft™ does not support audio profiles (including CTP) in any of its operating systems including in particular the current shipping of Windows XP™ service pack 2.
Access Point and WLAN Issues with Other Systems
For both Bluetooth and Wi-Fi as described above, the most commonly available AP in an office is a WLAN-enabled PC. However, problems exist with using these both for Bluetooth and Wi-Fi. In the case of Bluetooth, the current versions of Windows™ do not support audio profiles including CTP. In Wi-Fi enabled PCs they are set as devices rather than access points.
In addition to the protocol elements described above there are a number of problems presented when trying to provide coverage for a home or office in an affordable fashion:                i) WLAN range is limited in a home by in-building multi-path interference effects and blocking due to walls and other obstructions.        ii) WLANs are usually protected by firewalls which are not friendly to VoIP        iii) WLANs may not handle mobility very well in that the user's IP address may change as they travel from one access point (AP) to another.        iv) Home wiring is becoming very complex and requiring yet further physical wiring to provide additional WLAN points spread around the home or office is difficult.        v) In home environments, the selection of locations for access points (APs) is difficult as they must be in prominent locations to provide coverage, but when in such locations antenna efficiency may be compromised by having other objects placed close to or on top of them.        
The range of Bluetooth and Wi-Fi differs for different classes of system and in different scenarios. On one hand, the Bluetooth protocol has slightly better in-building range, but is hampered by the fact that Bluetooth systems are not commercially available with good diversity schemes. On the other hand, Wi-Fi systems have excellent diversity schemes where two antennas receive signals a few inches apart so that one or other antenna avoids interference, but are generally high-power only devices. A system is needed that optimizes the mix of Wi-Fi and Bluetooth systems and uses each to the best of its capability. A summary of the capabilities of different protocols is presented below.
TABLE 2RangeOtherModu-Range freeinconsid-TypelationFreq.spaceBuildingerationsBluetoothFrequency2.4 GHzCI 330MCIVery LowPowerHoppingCII+ 60MCII+Very LowCostSpreadCII 40MCIIComplexsoftwarestackSpectrumCII− 25MCII−GFSKCIII 10MCIII802.11aOFDM  5 GHz 80M 40MNointerference802.11bSpread2.4 GHz240M120MLow Cost,SpectrumbackwardDSSScompatible802.11gOFDM2.4 GHz120M 60MBest in(200)*Building athighthroughput*Advanced diversity methods significantly improve in building range by dramatically mitigating multi-path issues.
While Bluetooth has declined in usage as Wi-Fi enters the space. A number of advantages of Bluetooth over Wi-Fi exist: It is very low cost, it has about 1/10th the power consumption of the equivalent Wi-Fi function, it is already designed into roadmaps for the next two years, many low power Bluetooth headsets exist that are unlikely to be displaced by Wi-Fi. Therefore, any proposed system needs to cope with a mixed world of Bluetooth and Wi-Fi handsets and plan for the introduction of Wi-Max. At present there are no satisfactory Bluetooth/Wi-Fi dual mode access devices. In addition, many people already have Broadband access in place but the broadband router (ADSL Router) is often not ideally positioned to give good in home or in office coverage for an area. Existing Bluetooth handsets tend to be low power devices to keep power consumption low and to avoid interference with the WWAN circuitry in the phone. Additionally the phones are optimized for headset links that are perhaps only intended to be 10 meters or so. This means the phone is not optimized for maximum transmission range and provides a poor contribution to the link budget.
As stated above, one of the benefits of Bluetooth is the low cost link. It is a complex task to select a Bluetooth Profile that is available both on a Smart phone and on a PC. The following table is a reasonably comprehensive but far from exhaustive list of the profiles currently specified for Bluetooth.
TABLE 3Bluetooth Protocol ListGeneric Access Profile (GAP)Service Discovery Application Profile (SDAP)Cordless Telephony Profile (CTP)Intercom Profile (IP)Serial Port Profile (SPP)Headset Profile (HSP)Dial-up Networking Profile (DUNP)Fax ProfileLAN Access Profile (LAP)Generic Object Exchange Profile (GOEP)Object Push Profile (OPP)File Transfer Profile (FTP)Synchronization Profile (SP)Hands-Free Profile (HFP)Human Interface Device Profile (HID)Hard Copy Replacement Profile (HCRP)Basic Imaging Profile (BIP)Personal Area Networking Profile (PAN)Basic Printing Profile (BPP)Advanced Audio Distribution Profile (A2DP)Audio Video Remote Control Profile (AVRCP)SIM Access Profile (SAP)
For WLANs in general and 802.11 ‘Wi-Fi’ products in particular, they suffer from voice Quality of Service (QoS) issues because of their original design to carry data. The radio layer error recovery mechanism implemented at the Media Access Control (MAC) level retries packets at lower data rates if a packet is not acknowledged. In some cases, the handset spends more time transmitting error recovery packets than useful data. 802.11e (wireless MAC enhancements for QoS) provides a method for solving this but this still suffers from contention issues for the wireless medium particularly with respect to ‘unfriendly’ cohabitations such as Bluetooth with Wi-Fi (which share the same frequency band). When Bluetooth interferes with Wi-Fi, the Wi-Fi backs off its data rate to a lower bit rate, increasing the overall packet size in time. These longer packets have a higher probability of colliding with other users of the data network and causing yet more back off and retry events—a downward spiral which limits practical deployments to 6 users per Wi-Fi channel when the theoretical limit is more than 30. Creating a clean interference-free WLAN environment is highly desirable.
Another problem that can exist with these two types of systems is that handoff protocols might have to re-initiate authentication procedures. Fast roaming protocols, 802.11r and Inter Access Point Protocol (IAPP), 802.11f allow for the APs to switch in the sub 100 ms range and exchanges access point context so clients needn't go through the entire authentication process when roaming and handing off, but the context data (the pairing, authentication and channel data that specifies the parameters of a given link) exchanged is vendor proprietary, so handoff performance varies considerably. When roaming in a homogenous access point network with the same Service Set Identifier (SSID), the hand-off is usually fast but an improved and general method for handoff, and handover would be advantageous.
The problems with these systems can be classified as follows:—                1. Architectural Complexity        2. Mobile Device Complexity        3. Protocol mismatch requiring excessive translations        4. Lack of affordable coverage solutions        5. Poor co-existence between different WLAN systems        6. Lack of range due to poor link budget management and protocol issues        7. Slow handoff and handover.        8. Inability to implement peer-to-peer operation.        